Most security measure of applications, installed over an operating system (OS) in a desktop or server environment, are based on a security store protected by the OS.
However, there is a need for applications to be able to store secrets within the application and not to rely on external secrets store like.
Such use cases are found when applications are not permanently installed on a computer, or when such applications need to authenticate themselves to other applications executing on the same platform or elsewhere.
One such example is when an application is loaded from a portable storage device. A DRM application, for example, needs access to protected content securely stored on the portable device. Or it needs access to encrypted content wherein the key to decrypt such content is securely stored within the portable device.
Such an application needs to prove to the secure storage device that it is a legitimate application and not a rogue application trying to get hold of such protected content.
There are many other use cases wherein an instance of an executing application needs to prove to another executing application that it is a legitimate application.
Generally speaking, an application may need to use a secret shared with another. Or, it may need to use a private key to establish its identity to that application. In both cases, it needs to use a ‘secret’ accessible to the application.
Such secrets must be hidden within the application, because the nature of the use case is such that it cannot rely on the OS to guard that secret. This is especially true, when the application is executing on a non trusted host.
One known solution is to use a secret known only to a user who operates the application. This solution is not valid in use cases where the user is not trusted (DRM and software copy protection). Furthermore, even if a user is trusted, the host on which an application is executing may not be trusted.
Take the case of an internet café, wherein a spyware program may capture a password using a key-logger program.
A second possible solution, of hiding a secret within the storage of an operating system, is not satisfactory as it is not possible with non trusted hosts.
A third possible solution is to embed a secret within an executable code comprising an application or within a data file accessible to said application.
However, such embedded secrets are easy to find out, if all copies of the same program use the same embedded secret to facilitate authentication. Then, if a single copy of the application is breached and the secret found, then all copies of that application lose their protection.
An improvement of the third solution could be to embed a different secret in each copy of an application. Such a solution is not a good one either. A comparison program, could detect the location of the store secret where two copies of the same application differ from each other. Thus, extracting the secret from any instance and embedding it into another.
Furthermore, implementing such a scheme is more costly, since, devices which contain the application cannot be produced en mass from a single image, as each device would have to store a different copy of the program or an associated file.
Thus, it becomes apparent, that it would be advantageous if we could find a method that would provide for embedding a secret within an application instance in such a manner as to make retrieval and re-use of such a secret non practical for an attacker.